fix(clientsessiongroup): only query negotiated capabilities#2753
fix(clientsessiongroup): only query negotiated capabilities#2753mr-brobot wants to merge 1 commit into
Conversation
ClientSessionGroup._aggregate_components queried prompts, resources, and tools unconditionally on every connect, ignoring the ServerCapabilities returned by initialize(). A server that advertised only some of these (e.g. tools) returned JSON-RPC "Method not found" for the rest, which was swallowed into spurious WARNING logs. The MCP lifecycle spec requires clients to only use capabilities that were successfully negotiated. Gate each list_* call on the matching capability from session.initialize_result.capabilities, falling back to the prior unconditional behavior when initialize_result is absent so the existing MCPError handler still covers servers that advertise a capability but fail the method. Fixes modelcontextprotocol#2689 Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
mr-brobot
force-pushed
the
fix/clientsessiongroup-capabilities
branch
from
04133d5 to
6e03f80
Compare
StantonMatt
left a comment
StantonMatt
left a comment
There was a problem hiding this comment.
I found one edge in the new capability-gated path. When an already-initialized session advertises none of tools, prompts, or resources, connect_with_session() now skips all three list calls and then hits the existing cleanup block:
if not any((prompts_temp, resources_temp, tools_temp)):
del self._session_exit_stacks[session]For connect_with_session() there is no session exit stack registered, so this raises KeyError instead of connecting an empty session.
Local probe on this head:
capabilities=ServerCapabilities()
await ClientSessionGroup().connect_with_session(..., session)
=> KeyError <AsyncMock spec='ClientSession' ...>
list_tools awaited 0
list_prompts awaited 0
list_resources awaited 0
The new parametrized test covers exactly one advertised capability at a time, but not the zero-capability case that now takes this skip-all path. A small guard around the cleanup, or a zero-capability regression test, should close it.
Focused checks I ran locally:
uv run --frozen pytest tests/client/test_session_group.py -q-> 14 passeduv run --frozen ruff check src/mcp/client/session_group.py tests/client/test_session_group.pyuv run --frozen pyright src/mcp/client/session_group.py tests/client/test_session_group.pygit diff --check origin/main...HEAD
I also checked the red public checks / test (3.12, lowest-direct, windows-latest) job: the tests themselves completed (1744 passed, 99 skipped, 1 xfailed), then the job failed coverage at 99.96 < 100.00 on tests\interaction\transports\_stdio_server.py, which this branch does not touch.
2 participants
Summary
Fixes #2689
ClientSessionGroupqueried prompts, resources, and tools unconditionally on every connect, ignoring theServerCapabilitiesreturned byinitialize(). A server advertising only some capabilities (e.g. tools) returned JSON-RPCMethod not foundfor the rest, which was swallowed into spuriousWARNINGlogs — contrary to the lifecycle spec: clients MUST "Only use capabilities that were successfully negotiated."Changes
_aggregate_componentsnow gates eachlist_*call on the matching capability fromsession.initialize_result.capabilities.MCPErrorfallback is preserved for servers that advertise a capability but still fail the method; a missinginitialize_resultfalls back to the prior unconditional behavior.test_client_session_group_skips_unsupported_capabilities, parametrized over tools/prompts/resources-only servers.The same code path exists on
v1.xand likely warrants a[v1.x]backport.Note
I followed the suggestion strictly, but I think the fallback behavior for "misbehaving servers" has questionable value. Sharing as-is for feedback.
🤖 Generated with Claude Code